1. Field of the Invention
The present invention relates to the relationship between firmware and hardware in a computer system, and more specifically to software control of hardware.
2. Background of the Related Art
In 1996, Microsoft and other computer companies developed the Advanced Configuration and Power Interface (ACPI) paradigm. The ACPI has been intended to replace both the plug-and-play and the Advanced Power Management (APM), and virtually eliminate the need for a system Basic Input/Output System (BIOS) to configure the system. The ACPI operating system performs all of the functions previously performed by plug-and-play (PnP) and the Advanced Power Management (APM), reducing the system Basic Input Output System to a small collection of routines callable from the operating system.
Microsoft and other computer companies have determined to relegate to the operating system (OS) various functions that had previously been performed by the system Basic Input Output System. Traditionally when power has been applied to a computer system, a system Basic Input Output System, typically residing in ROM or PROM (and therefore difficult to modify) or in an Initial Program Load (IPL) device that cannot be disabled, executes immediately. The system Basic Input Output System includes firmware that configures the computer system, and provides a variety of other functions. In many systems, following the execution of the system Basic Input Output System, a Plug-and-Play Basic Input Output System and an Advanced Power Management Basic Input Output System execute, with related utilities. (The Plug-and-Play Basic Input Output System is not to be confused with the system Basic Input Output System.) The Plug-and-Play Basic Input Output System re-configures the system either dynamically or statically to allow the operating system to initialize. The Advanced Power Management controls system power, including sleep states and power states. ACPI replaces both the Plug-and-Play Basic Input Output System and Advanced Power Management Basic Input Output System, and other system initialization functionality, by providing operating systems and a platform/device interface that can perform these tasks in a more centralized paradigm. (The Advanced Power Management Basic Input Output System is not to be confused with either the system Basic Input Output System or the PnP Basic Input Output System.) However, to function properly, ACPI also requires compliance of platform hardware, imposing certain ACPI compatible hardware interface requirements on computer manufacturers, such that all devices will be compatible with the ACPI compatible operating systems. Thus, from the perspective of the manufacturer, the ACPI specification may be seen as a hardware interface specification.
The ACPI specification creates certain hardware components and extensions to facilitate the hardware interface. One of the additional hardware extensions necessary under the ACPI specification has been the general purpose event (OPE) status register. This register contains a set of event indicators, the occurrence of any of which causes a system control interrupt (SCI). The System Control Interrupt, visible to the operating system, operates within the operating system much as a System Management Interrupt (SMI) operates within a manufacturer-provided software package. ACPI operating systems use the System Control Interrupt handler to respond to events, while legacy systems use some type of transparent interrupt handler to respond to these events (that is, a System Management Interrupt handler).
The General Purpose Event status register includes a number of status bits, and each manufacturer has been expected to interconnect hardware signals such that the appropriate hardware events cause the assertion of the appropriate General Purpose Event status bit. Handling of the event has been relegated to the device driver or to manufacturer-provided p-code. One type of p-code, AML (ACPI Machine Language), is a virtual machine language, compiled from a pseudocode referred to as ASL (ACPI Source Language). This machine language is the p-code in which device control methods are written, and which is understandable to all ACPI-compatible operating systems. An ACPI operating system does not detect general purpose events other than through the General Purpose Event status register, and in the ACPI paradigm only the operating system can load and execute a device control method. Moreover, only the operating system can perform power functions, such as put the processor into a sleep state or perform a system wake-up. Thus, platform devices must provide the proper information to the General Purpose Event status register's status bit, at the proper time, to be detected by the operating system.
Unfortunately, while conforming hardware interface design to a single standard provides many of the benefits of standardization, it also imposes a burden on computer manufacturers. It can be extremely difficult for a hardware designer to develop a design architecture that is compatible with the General Purpose Event status register circuitry. Due to the complexity of the ACPI and platform control, some hardware designs may not be able to access the General Purpose Event status register and cause the system control interrupt when necessary. Many hardware designers may therefore be required to add external circuitry in order to connect their devices with the appropriate General Purpose Event status register bits.
From the perspective of ACPI, ACPI compatibility and compliance has been the responsibility of the device developer. Therefore, the manufacturer must interconnect hardware signals from devices to the General Purpose Event registers, such that all of the interconnections comply with ACPI. Therefore, if a manufacturer changes hardware design, the manufacturer must ensure that the new design also complies with the ACPI requirements relating to the General Purpose Event status registers. Where the interconnections do not comply, the manufacturer must provide additional external circuitry to force the signal from the devices to comply with the requirements of the General Purpose Event registers. Although this may not be a significant problem for the manufacturer if detected very early in the product development, once the designer has begun developing the circuitry to implement the product, changes necessary merely to interface with the general purpose event status register are increasingly expensive and difficult to implement.